| 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
| ||
|
Message-ID: <cdbaae48-8051-4b0d-93b7-d6e0e925b924@amd.com> Date: Mon, 1 Dec 2025 20:55:49 -0600 From: Mario Limonciello <mario.limonciello@....com> To: Samuel Wu <wusamuel@...gle.com>, Huang Rui <ray.huang@....com>, "Gautham R. Shenoy" <gautham.shenoy@....com>, Perry Yuan <perry.yuan@....com>, Jonathan Corbet <corbet@....net>, "Rafael J. Wysocki" <rafael@...nel.org>, Viresh Kumar <viresh.kumar@...aro.org>, Steven Rostedt <rostedt@...dmis.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> Cc: christian.loehle@....com, 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 v2 2/2] cpufreq: Documentation update for trace_policy_frequency On 12/1/2025 2:13 PM, Samuel Wu wrote: > Documentation update corresponding to replace the cpu_frequency trace > event with the policy_frequency trace event. > > Signed-off-by: Samuel Wu <wusamuel@...gle.com> > --- Reviewed-by: Mario Limonciello <mario.limonciello@....com> # amd-pstate > Documentation/admin-guide/pm/amd-pstate.rst | 10 +++++----- > Documentation/admin-guide/pm/intel_pstate.rst | 14 +++++++------- > Documentation/trace/events-power.rst | 2 +- > 3 files changed, 13 insertions(+), 13 deletions(-) > > diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst > index e1771f2225d5..e110854ece88 100644 > --- a/Documentation/admin-guide/pm/amd-pstate.rst > +++ b/Documentation/admin-guide/pm/amd-pstate.rst > @@ -503,8 +503,8 @@ Trace Events > -------------- > > There are two static trace events that can be used for ``amd-pstate`` > -diagnostics. One of them is the ``cpu_frequency`` trace event generally used > -by ``CPUFreq``, and the other one is the ``amd_pstate_perf`` trace event > +diagnostics. One of them is the ``policy_frequency`` trace event generally > +used by ``CPUFreq``, and the other one is the ``amd_pstate_perf`` trace event > specific to ``amd-pstate``. The following sequence of shell commands can > be used to enable them and see their output (if the kernel is > configured to support event tracing). :: > @@ -531,9 +531,9 @@ configured to support event tracing). :: > <idle>-0 [003] d.s.. 4995.980971: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=3 changed=false fast_switch=true > <idle>-0 [011] d.s.. 4995.980996: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=11 changed=false fast_switch=true > > -The ``cpu_frequency`` trace event will be triggered either by the ``schedutil`` scaling > -governor (for the policies it is attached to), or by the ``CPUFreq`` core (for the > -policies with other scaling governors). > +The ``policy_frequency`` trace event will be triggered either by the > +``schedutil`` scaling governor (for the policies it is attached to), or by the > +``CPUFreq`` core (for the policies with other scaling governors). > > > Tracer Tool > diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst > index fde967b0c2e0..274c9208f342 100644 > --- a/Documentation/admin-guide/pm/intel_pstate.rst > +++ b/Documentation/admin-guide/pm/intel_pstate.rst > @@ -822,23 +822,23 @@ Trace Events > ------------ > > There are two static trace events that can be used for ``intel_pstate`` > -diagnostics. One of them is the ``cpu_frequency`` trace event generally used > -by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event specific > -to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` only if > -it works in the :ref:`active mode <active_mode>`. > +diagnostics. One of them is the ``policy_frequency`` trace event generally > +used by ``CPUFreq``, and the other one is the ``pstate_sample`` trace event > +specific to ``intel_pstate``. Both of them are triggered by ``intel_pstate`` > +only if it works in the :ref:`active mode <active_mode>`. > > The following sequence of shell commands can be used to enable them and see > their output (if the kernel is generally configured to support event tracing):: > > # cd /sys/kernel/tracing/ > # echo 1 > events/power/pstate_sample/enable > - # echo 1 > events/power/cpu_frequency/enable > + # echo 1 > events/power/policy_frequency/enable > # cat trace > gnome-terminal--4510 [001] ..s. 1177.680733: pstate_sample: core_busy=107 scaled=94 from=26 to=26 mperf=1143818 aperf=1230607 tsc=29838618 freq=2474476 > - cat-5235 [002] ..s. 1177.681723: cpu_frequency: state=2900000 cpu_id=2 > + cat-5235 [002] ..s. 1177.681723: policy_frequency: state=2900000 cpu_id=2 policy_cpus=04 > > If ``intel_pstate`` works in the :ref:`passive mode <passive_mode>`, the > -``cpu_frequency`` trace event will be triggered either by the ``schedutil`` > +``policy_frequency`` trace event will be triggered either by the ``schedutil`` > scaling governor (for the policies it is attached to), or by the ``CPUFreq`` > core (for the policies with other scaling governors). > > diff --git a/Documentation/trace/events-power.rst b/Documentation/trace/events-power.rst > index f45bf11fa88d..f013c74b932f 100644 > --- a/Documentation/trace/events-power.rst > +++ b/Documentation/trace/events-power.rst > @@ -26,8 +26,8 @@ cpufreq. > :: > > cpu_idle "state=%lu cpu_id=%lu" > - cpu_frequency "state=%lu cpu_id=%lu" > cpu_frequency_limits "min=%lu max=%lu cpu_id=%lu" > + policy_frequency "state=%lu cpu_id=%lu policy_cpus=%*pb" > > A suspend event is used to indicate the system going in and out of the > suspend mode:
Powered by blists - more mailing lists