linux-kernel - Re: [PATCH v3 1/2] cpufreq: Replace trace_cpu_frequency with trace_policy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251204134650.2d9fd3ff@gandalf.local.home>
Date: Thu, 4 Dec 2025 13:46:50 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Christian Loehle <christian.loehle@....com>, Samuel Wu
 <wusamuel@...gle.com>, Huang Rui <ray.huang@....com>, "Gautham R. Shenoy"
 <gautham.shenoy@....com>, Mario Limonciello <mario.limonciello@....com>,
 Perry Yuan <perry.yuan@....com>, Jonathan Corbet <corbet@....net>, Viresh
 Kumar <viresh.kumar@...aro.org>, Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Srinivas Pandruvada
 <srinivas.pandruvada@...ux.intel.com>, Len Brown <lenb@...nel.org>, Alexei
 Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
 <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>, Song Liu
 <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>, John Fastabend
 <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, Stanislav
 Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa
 <jolsa@...nel.org>, Peter Zijlstra <peterz@...radead.org>, Ingo Molnar
 <mingo@...hat.com>, Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung
 Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>, Alexander
 Shishkin <alexander.shishkin@...ux.intel.com>, Ian Rogers
 <irogers@...gle.com>, Adrian Hunter <adrian.hunter@...el.com>, James Clark
 <james.clark@...aro.org>, kernel-team@...roid.com,
 linux-pm@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 bpf@...r.kernel.org, linux-perf-users@...r.kernel.org
Subject: Re: [PATCH v3 1/2] cpufreq: Replace trace_cpu_frequency with
 trace_policy_frequency

On Thu, 4 Dec 2025 18:24:57 +0100
"Rafael J. Wysocki" <rafael@...nel.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