* [PATCH] thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power
@ 2019-05-02 18:32 Matthias Kaehlcke
2019-05-03 7:21 ` Viresh Kumar
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Matthias Kaehlcke @ 2019-05-02 18:32 UTC (permalink / raw)
To: Amit Daniel Kachhap, Viresh Kumar, Javi Merino, Zhang Rui,
Eduardo Valentin, Daniel Lezcano
Cc: linux-pm, linux-kernel, Douglas Anderson, Matthias Kaehlcke
The CPU load values passed to the thermal_power_cpu_get_power
tracepoint are zero for all CPUs, unless, unless the
thermal_power_cpu_limit tracepoint is enabled too:
irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power:
cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815
vs
irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power:
cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959
irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit:
cpus=0000000f freq=408000 cdev_state=10 power=416
There seems to be no good reason for omitting the CPU load information
depending on another tracepoint. My guess is that the intention was to
check whether thermal_power_cpu_get_power is (still) enabled, however
'load_cpu != NULL' already indicates that it was at least enabled when
cpufreq_get_requested_power() was entered, there seems little gain
from omitting the assignment if the tracepoint was just disabled, so
just remove the check.
Fixes: 6828a4711f99 ("thermal: add trace events to the power allocator governor")
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
---
drivers/thermal/cpu_cooling.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index f7c1f49ec87f..b437804e099b 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -458,7 +458,7 @@ static int cpufreq_get_requested_power(struct thermal_cooling_device *cdev,
load = 0;
total_load += load;
- if (trace_thermal_power_cpu_limit_enabled() && load_cpu)
+ if (load_cpu)
load_cpu[i] = load;
i++;
--
2.21.0.593.g511ec345e18-goog
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power
2019-05-02 18:32 [PATCH] thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power Matthias Kaehlcke
@ 2019-05-03 7:21 ` Viresh Kumar
2019-05-03 21:11 ` Daniel Lezcano
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Viresh Kumar @ 2019-05-03 7:21 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Amit Daniel Kachhap, Javi Merino, Zhang Rui, Eduardo Valentin,
Daniel Lezcano, linux-pm, linux-kernel, Douglas Anderson
On 02-05-19, 11:32, Matthias Kaehlcke wrote:
> The CPU load values passed to the thermal_power_cpu_get_power
> tracepoint are zero for all CPUs, unless, unless the
> thermal_power_cpu_limit tracepoint is enabled too:
>
> irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power:
> cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815
>
> vs
>
> irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power:
> cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959
> irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit:
> cpus=0000000f freq=408000 cdev_state=10 power=416
>
> There seems to be no good reason for omitting the CPU load information
> depending on another tracepoint. My guess is that the intention was to
> check whether thermal_power_cpu_get_power is (still) enabled, however
> 'load_cpu != NULL' already indicates that it was at least enabled when
> cpufreq_get_requested_power() was entered, there seems little gain
> from omitting the assignment if the tracepoint was just disabled, so
> just remove the check.
>
> Fixes: 6828a4711f99 ("thermal: add trace events to the power allocator governor")
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> drivers/thermal/cpu_cooling.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index f7c1f49ec87f..b437804e099b 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -458,7 +458,7 @@ static int cpufreq_get_requested_power(struct thermal_cooling_device *cdev,
> load = 0;
>
> total_load += load;
> - if (trace_thermal_power_cpu_limit_enabled() && load_cpu)
> + if (load_cpu)
> load_cpu[i] = load;
>
> i++;
@Javi: I find this change to be fine, do you have any comments on this ?
--
viresh
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power
2019-05-02 18:32 [PATCH] thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power Matthias Kaehlcke
2019-05-03 7:21 ` Viresh Kumar
@ 2019-05-03 21:11 ` Daniel Lezcano
2019-05-10 6:38 ` Javi Merino
2019-05-10 6:42 ` Viresh Kumar
3 siblings, 0 replies; 5+ messages in thread
From: Daniel Lezcano @ 2019-05-03 21:11 UTC (permalink / raw)
To: Matthias Kaehlcke, Amit Daniel Kachhap, Viresh Kumar,
Javi Merino, Zhang Rui, Eduardo Valentin
Cc: linux-pm, linux-kernel, Douglas Anderson
On 02/05/2019 20:32, Matthias Kaehlcke wrote:
> The CPU load values passed to the thermal_power_cpu_get_power
> tracepoint are zero for all CPUs, unless, unless the
> thermal_power_cpu_limit tracepoint is enabled too:
>
> irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power:
> cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815
>
> vs
>
> irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power:
> cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959
> irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit:
> cpus=0000000f freq=408000 cdev_state=10 power=416
>
> There seems to be no good reason for omitting the CPU load information
> depending on another tracepoint. My guess is that the intention was to
> check whether thermal_power_cpu_get_power is (still) enabled, however
> 'load_cpu != NULL' already indicates that it was at least enabled when
> cpufreq_get_requested_power() was entered, there seems little gain
> from omitting the assignment if the tracepoint was just disabled, so
> just remove the check.
>
> Fixes: 6828a4711f99 ("thermal: add trace events to the power allocator governor")
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
Yes, load_cpu is needed in any case for both traces. The change makes sense.
Reviewed-by: Daniel Lezcano <daniel.lezcano@linaro.org>
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power
2019-05-02 18:32 [PATCH] thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power Matthias Kaehlcke
2019-05-03 7:21 ` Viresh Kumar
2019-05-03 21:11 ` Daniel Lezcano
@ 2019-05-10 6:38 ` Javi Merino
2019-05-10 6:42 ` Viresh Kumar
3 siblings, 0 replies; 5+ messages in thread
From: Javi Merino @ 2019-05-10 6:38 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Amit Daniel Kachhap, Viresh Kumar, Zhang Rui, Eduardo Valentin,
Daniel Lezcano, linux-pm, linux-kernel, Douglas Anderson
On Thu, May 02, 2019 at 11:32:38AM -0700, Matthias Kaehlcke wrote:
> The CPU load values passed to the thermal_power_cpu_get_power
> tracepoint are zero for all CPUs, unless, unless the
> thermal_power_cpu_limit tracepoint is enabled too:
>
> irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power:
> cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815
>
> vs
>
> irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power:
> cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959
> irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit:
> cpus=0000000f freq=408000 cdev_state=10 power=416
>
> There seems to be no good reason for omitting the CPU load information
> depending on another tracepoint. My guess is that the intention was to
> check whether thermal_power_cpu_get_power is (still) enabled, however
> 'load_cpu != NULL' already indicates that it was at least enabled when
> cpufreq_get_requested_power() was entered, there seems little gain
> from omitting the assignment if the tracepoint was just disabled, so
> just remove the check.
>
> Fixes: 6828a4711f99 ("thermal: add trace events to the power allocator governor")
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Yep, looks good to me.
Acked-by: Javi Merino <javi.merino@kernel.org>
> ---
> drivers/thermal/cpu_cooling.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index f7c1f49ec87f..b437804e099b 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -458,7 +458,7 @@ static int cpufreq_get_requested_power(struct thermal_cooling_device *cdev,
> load = 0;
>
> total_load += load;
> - if (trace_thermal_power_cpu_limit_enabled() && load_cpu)
> + if (load_cpu)
> load_cpu[i] = load;
>
> i++;
> --
> 2.21.0.593.g511ec345e18-goog
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power
2019-05-02 18:32 [PATCH] thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power Matthias Kaehlcke
` (2 preceding siblings ...)
2019-05-10 6:38 ` Javi Merino
@ 2019-05-10 6:42 ` Viresh Kumar
3 siblings, 0 replies; 5+ messages in thread
From: Viresh Kumar @ 2019-05-10 6:42 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: Amit Daniel Kachhap, Javi Merino, Zhang Rui, Eduardo Valentin,
Daniel Lezcano, linux-pm, linux-kernel, Douglas Anderson
On 02-05-19, 11:32, Matthias Kaehlcke wrote:
> The CPU load values passed to the thermal_power_cpu_get_power
> tracepoint are zero for all CPUs, unless, unless the
> thermal_power_cpu_limit tracepoint is enabled too:
>
> irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power:
> cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815
>
> vs
>
> irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power:
> cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959
> irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit:
> cpus=0000000f freq=408000 cdev_state=10 power=416
>
> There seems to be no good reason for omitting the CPU load information
> depending on another tracepoint. My guess is that the intention was to
> check whether thermal_power_cpu_get_power is (still) enabled, however
> 'load_cpu != NULL' already indicates that it was at least enabled when
> cpufreq_get_requested_power() was entered, there seems little gain
> from omitting the assignment if the tracepoint was just disabled, so
> just remove the check.
>
> Fixes: 6828a4711f99 ("thermal: add trace events to the power allocator governor")
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> drivers/thermal/cpu_cooling.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index f7c1f49ec87f..b437804e099b 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -458,7 +458,7 @@ static int cpufreq_get_requested_power(struct thermal_cooling_device *cdev,
> load = 0;
>
> total_load += load;
> - if (trace_thermal_power_cpu_limit_enabled() && load_cpu)
> + if (load_cpu)
> load_cpu[i] = load;
>
> i++;
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2019-05-10 6:42 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-02 18:32 [PATCH] thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power Matthias Kaehlcke
2019-05-03 7:21 ` Viresh Kumar
2019-05-03 21:11 ` Daniel Lezcano
2019-05-10 6:38 ` Javi Merino
2019-05-10 6:42 ` Viresh Kumar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).