[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b97dab99-6796-3427-0c6d-57ea6c3dfb1f@arm.com>
Date: Thu, 7 Nov 2019 14:00:22 +0100
From: Dietmar Eggemann <dietmar.eggemann@....com>
To: Thara Gopinath <thara.gopinath@...aro.org>, mingo@...hat.com,
peterz@...radead.org, ionela.voinescu@....com,
vincent.guittot@...aro.org, rui.zhang@...el.com,
edubezval@...il.com, qperret@...gle.com
Cc: linux-kernel@...r.kernel.org, amit.kachhap@...il.com,
javi.merino@...nel.org, daniel.lezcano@...aro.org
Subject: Re: [Patch v5 5/6] thermal/cpu-cooling: Update thermal pressure in
case of a maximum frequency capping
On 06/11/2019 13:50, Dietmar Eggemann wrote:
> On 05/11/2019 19:49, Thara Gopinath wrote:
>
> [...]
>
>> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
>> index 391f397..c65b7c4 100644
>> --- a/drivers/thermal/cpu_cooling.c
>> +++ b/drivers/thermal/cpu_cooling.c
>> @@ -218,6 +218,27 @@ static u32 cpu_power_to_freq(struct cpufreq_cooling_device *cpufreq_cdev,
>> }
>>
>> /**
>> + * update_sched_max_capacity - update scheduler about change in cpu
>> + * max frequency.
>> + * @cpus: list of cpus whose max capacity needs udating in scheduler.
>> + * @cur_max_freq: current maximum frequency.
>> + * @max_freq: highest possible frequency.
>> + */
>> +static void update_sched_max_capacity(struct cpumask *cpus,
>> + unsigned int cur_max_freq,
>> + unsigned int max_freq)
>> +{
>> + int cpu;
>> + unsigned long capacity;
>> +
>> + for_each_cpu(cpu, cpus) {
>> + capacity = cur_max_freq * arch_scale_cpu_capacity(cpu);
>> + capacity /= max_freq;
>> + update_thermal_pressure(cpu, capacity);
>> + }
>> +}
>> +
>> +/**
>
> Have you seen
> https://lore.kernel.org/r/2b19d7da-412c-932f-7251-110eadbef3e3@arm.com ?
>
> Also the naming 'update_thermal_pressure()' is not really suitable for
> an external task scheduler interface. If I see this called in the
> cooling device code, I wouldn't guess that this is a task scheduler
> interface.
>
> [...]
The current interface to bring in frequency and uarch (CPU) invariance
information into the task scheduler is arch_scale_[freq|cpu]_capacity.
So why not follow this approach for the thermal->sched interface?
+#ifndef arch_scale_thermal_capacity
+static __always_inline
+unsigned long arch_scale_thermal_capacity(int cpu)
+{
+ return 0;
+}
+#endif
Leave per_cpu(thermal_pressure, cpu) within cpu cooling and let cpu
cooling (or even platform) #define arch_scale_thermal_capacity.
Powered by blists - more mailing lists