Re: [PATCH v3 1/2] cpufreq: Replace trace_cpu_frequency with trace_policy_frequency

[Steven Rostedt <rostedt@goodmis.org>]

On Thu, 4 Dec 2025 18:24:57 +0100
"Rafael J. Wysocki" <rafael@kernel.org> wrote:

> > I'm not exactly sure what you mean here. There is an "onchange" trigger you
> > can use to trigger a synthetic event whenever a change happens. But I think
> > the data here wants to know which CPU had its policy change. Hence the CPU
> > mask.  
> 
> IIUC he wants to trace frequency changes per policy, not per CPU
> (because there are cases in which multiple CPUs belong to one policy
> and arguably the frequency doesn't need to be traced for all of them),
> but tooling should know which CPUs belong to the same policy, so it
> should be straightforward to use that knowledge when processing the
> traces.

In case you only care about frequency changes, you could do this:

 # echo 'freq_change u32 state;' > /sys/kernel/tracing/synthetic_events 
 # echo 'hist:keys=common_type:s=state:onchange($s).trace(freq_change,$s)' > /sys/kernel/tracing/events/power/cpu_frequency/trigger 
 # echo 1 > /sys/kernel/tracing/events/synthetic/freq_change/enable 
 # cat /sys/kernel/tracing/trace
# tracer: nop
#
# entries-in-buffer/entries-written: 2833/2833   #P:56
#
#                                _-----=> irqs-off/BH-disabled
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| / _-=> migrate-disable
#                              |||| /     delay
#           TASK-PID     CPU#  |||||  TIMESTAMP  FUNCTION
#              | |         |   |||||     |         |
             sed-596089  [034] d..5. 2687140.288806: freq_change: state=2000000
            bash-596090  [020] d.s4. 2687140.290407: freq_change: state=1900000
          <idle>-0       [028] d.s7. 2687140.290425: freq_change: state=3000000
            bash-596090  [020] d..5. 2687140.291152: freq_change: state=1900000
          <idle>-0       [000] dNs5. 2687140.326526: freq_change: state=1200000
       CPU 3/KVM-10724   [019] d.s5. 2687140.358418: freq_change: state=2100000
       CPU 6/KVM-10727   [021] d.h5. 2687140.394403: freq_change: state=1300000
       CPU 6/KVM-10727   [021] d.h5. 2687140.398403: freq_change: state=1400000
       CPU 6/KVM-10727   [021] d.h5. 2687140.402402: freq_change: state=1500000
       CPU 6/KVM-10727   [021] d.h5. 2687140.406400: freq_change: state=1600000
       CPU 6/KVM-10727   [021] d.h5. 2687140.410404: freq_change: state=1700000
[..]

Which BTW, I'll be giving a talk about synthetic events at OSS in Tokyo ;-)
   (cheap plug!)

https://ossjapan2025.sched.com/event/29FoB/synthetic-events-and-tracing-latency-within-the-kernel-steven-rostedt-google?iframe=yes&w=100%&sidebar=yes&bg=no

-- Steve