The Energy Model (EM) supports runtime modifications. Track the changes
in order to do post-processing analysis. Don't use arrays in the trace
event, since they are not properly supported by the tools. Instead use
simple "unroll" with emitting the trace event for each EM array entry
with proper ID information. The older debugging mechanism which was
the simple debugfs which dumping the EM content won't be sufficient for
the modifiable EM purpose. This trace event mechanism would address the
needs.
Signed-off-by: Lukasz Luba <[email protected]>
---
include/trace/events/energy_model.h | 46 +++++++++++++++++++++++++++++
kernel/power/energy_model.c | 3 ++
2 files changed, 49 insertions(+)
create mode 100644 include/trace/events/energy_model.h
diff --git a/include/trace/events/energy_model.h b/include/trace/events/energy_model.h
new file mode 100644
index 000000000000..f70babeb5dde
--- /dev/null
+++ b/include/trace/events/energy_model.h
@@ -0,0 +1,46 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM energy_model
+
+#if !defined(_TRACE_ENERGY_MODEL_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_ENERGY_MODEL_H
+
+#include <linux/tracepoint.h>
+
+TRACE_EVENT(em_perf_state,
+ TP_PROTO(const char *dev_name, int nr_perf_states, int state,
+ unsigned long ps_frequency, unsigned long ps_power,
+ unsigned long ps_cost, unsigned long ps_flags),
+
+ TP_ARGS(dev_name, nr_perf_states, state, ps_frequency, ps_power, ps_cost,
+ ps_flags),
+
+ TP_STRUCT__entry(
+ __string(name, dev_name)
+ __field(int, num_states)
+ __field(int, state)
+ __field(unsigned long, frequency)
+ __field(unsigned long, power)
+ __field(unsigned long, cost)
+ __field(unsigned long, flags)
+ ),
+
+ TP_fast_assign(
+ __assign_str(name, dev_name);
+ __entry->num_states = nr_perf_states;
+ __entry->state = state;
+ __entry->frequency = ps_frequency;
+ __entry->power = ps_power;
+ __entry->cost = ps_cost;
+ __entry->flags = ps_flags;
+ ),
+
+ TP_printk("dev_name=%s nr_perf_states=%d state=%d frequency=%lu power=%lu cost=%lu flags=%lu",
+ __get_str(name), __entry->num_states, __entry->state,
+ __entry->frequency, __entry->power, __entry->cost,
+ __entry->flags)
+);
+#endif /* _TRACE_ENERGY_MODEL_H */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
index fd1066dcf38b..61d349fec545 100644
--- a/kernel/power/energy_model.c
+++ b/kernel/power/energy_model.c
@@ -17,6 +17,9 @@
#include <linux/sched/topology.h>
#include <linux/slab.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/energy_model.h>
+
/*
* Mutex serializing the registrations of performance domains and letting
* callbacks defined by drivers sleep.
--
2.25.1
On 12/05/2023 11:57, Lukasz Luba wrote:
> The Energy Model (EM) supports runtime modifications. Track the changes
> in order to do post-processing analysis. Don't use arrays in the trace
> event, since they are not properly supported by the tools. Instead use
> simple "unroll" with emitting the trace event for each EM array entry
> with proper ID information. The older debugging mechanism which was
> the simple debugfs which dumping the EM content won't be sufficient for
> the modifiable EM purpose. This trace event mechanism would address the
> needs.
Do we really need a full trace_event for this? Can we not follow the
task scheduler rule which says no new trace_events and use a trace_point
here? The footprint in the kernel would be so much smaller.
E.g. pelt_cfs_tp
0 sched.h 694 DECLARE_TRACE(pelt_cfs_tp,
1 core.c 106 EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_cfs_tp);
2 fair.c 3937 trace_pelt_cfs_tp(cfs_rq);
And then this patch should be after the section with the functional changes.
[...]
On 5/30/23 11:03, Dietmar Eggemann wrote:
> On 12/05/2023 11:57, Lukasz Luba wrote:
>> The Energy Model (EM) supports runtime modifications. Track the changes
>> in order to do post-processing analysis. Don't use arrays in the trace
>> event, since they are not properly supported by the tools. Instead use
>> simple "unroll" with emitting the trace event for each EM array entry
>> with proper ID information. The older debugging mechanism which was
>> the simple debugfs which dumping the EM content won't be sufficient for
>> the modifiable EM purpose. This trace event mechanism would address the
>> needs.
>
> Do we really need a full trace_event for this? Can we not follow the
> task scheduler rule which says no new trace_events and use a trace_point
> here? The footprint in the kernel would be so much smaller.
>
> E.g. pelt_cfs_tp
>
> 0 sched.h 694 DECLARE_TRACE(pelt_cfs_tp,
> 1 core.c 106 EXPORT_TRACEPOINT_SYMBOL_GPL(pelt_cfs_tp);
> 2 fair.c 3937 trace_pelt_cfs_tp(cfs_rq);
>
> And then this patch should be after the section with the functional changes.
>
> [...]
I agree. I will change that approach and create tracepoint. Also, I'll
move it to the patch at the end of the functional changes.