From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Jean Pihet <jean.pihet@newoldbits.com>
Cc: Thomas Renninger <trenn@suse.de>, Ingo Molnar <mingo@elte.hu>,
Arjan van de Ven <arjan@linux.intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Len Brown <len.brown@intel.com>,
arjan@infradead.org, Kevin Hilman <khilman@deeprootsystems.com>,
linux-kernel@vger.kernel.org,
linux-pm@lists.linux-foundation.org, linux-omap@vger.kernel.org,
linux-perf-users@vger.kernel.org,
linux-trace-users@vger.kernel.org
Subject: Re: [PATCH] tracing, perf: add more power related events
Date: Wed, 22 Sep 2010 20:49:17 +0200 [thread overview]
Message-ID: <201009222049.18154.rjw@sisk.pl> (raw)
In-Reply-To: <AANLkTimMAr9kEzybFGai3qGyXx36v055iPpXq_C1vW8C@mail.gmail.com>
[Dropping discuss@lesswatts.org from the CC list.]
On Wednesday, September 22, 2010, Jean Pihet wrote:
> Hi,
>
> Here is a patch that redefines the power events API. The advantages
> are: easier maintainance of the kernel and the
> user space tools, a cleaner and more generic interface, more
> parameters for fine tracing and even documentation!
>
> Thomas, this patch has your patch above merged in ('power-trace: Use
> power_switch_state instead of power_start and power_end'). The revised
> ACPI patch is coming asap.
>
> The trace points for x86 and OMAP are also udated accordingly.
>
> The pytimechart tool needs an update for the new API. This can be done
> as soon as the kernel code gets merged in.
> Please note the point below about the existing code in builtin-timechart.c.
>
> On Sat, Sep 18, 2010 at 12:26 AM, Thomas Renninger <trenn@suse.de> wrote:
> > On Friday 17 September 2010 18:24:12 Ingo Molnar wrote:
> >>
> >> * Thomas Renninger <trenn@suse.de> wrote:
> >>
> >> > On Friday 17 September 2010 16:24:59 Ingo Molnar wrote:
> >
> >> [ You dont even have to document it, as good code is self-explanatory ;-) ]
> > I recently posted a patch exporting some things through /sys/kernel/debug/...
> > Greg complained that a file for Documentation/ABI/{testing,stable}/* is missing
> > and I fully agree.
> The proposed patch has the documentation in
> Documentation/trace/events-power.txt.
>
> > If different userspace apps should make use of this (in above case nobody
> > than my debug userspace tool will...) and this should be called something like an API,
> > it should be documented and if something changes, it should
> > first be marked deprecated, etc.
> Note: the exsiting code in tools/perf/builtin-timechart.c needs an
> update for the new events API. Is this code still maintained? I not,
> could pytimechart be merged in instead?
>
> Feedback is welcome!
>
> >
> > Thomas
> >
>
> Thanks,
> Jean
>
> ---
> From f37d1875050d33273b10e99497b4059b37e6680d Mon Sep 17 00:00:00 2001
> From: Jean Pihet <jean.pihet@newoldbits.com>
> Date: Wed, 22 Sep 2010 17:10:47 +0200
> Subject: [PATCH] tools, perf: redefine the power events API
>
> Redefine the API with:
> - power_switch_state for C-, P- and S-states,
> - clock and power_domain events
>
> The new API allows easier maintainance of the kernel and the
> user space tools, a cleaner and more generic interface,
> more parameters for fine tracing and even documentation.
>
> The new events are used by the x86 and OMAP platforms.
>
> Signed-off-by: Jean Pihet <j-pihet@ti.com>
> ---
> Documentation/trace/events-power.txt | 70 +++++++++++++++++++++++++
> arch/arm/mach-omap2/cpuidle34xx.c | 3 +
> arch/arm/mach-omap2/pm34xx.c | 11 ++++
> arch/arm/mach-omap2/powerdomain.c | 3 +
> arch/arm/plat-omap/clock.c | 13 ++++-
> arch/arm/plat-omap/cpu-omap.c | 3 +
> arch/x86/kernel/process.c | 13 +++--
> arch/x86/kernel/process_32.c | 3 +-
> arch/x86/kernel/process_64.c | 3 +-
> drivers/cpufreq/cpufreq.c | 3 +-
> drivers/cpuidle/cpuidle.c | 2 +-
> drivers/idle/intel_idle.c | 2 +-
> include/trace/events/power.h | 95 ++++++++++++++++------------------
> kernel/trace/power-traces.c | 2 -
> 14 files changed, 161 insertions(+), 65 deletions(-)
> create mode 100644 Documentation/trace/events-power.txt
>
> diff --git a/Documentation/trace/events-power.txt
> b/Documentation/trace/events-power.txt
> new file mode 100644
> index 0000000..967f842
> --- /dev/null
> +++ b/Documentation/trace/events-power.txt
> @@ -0,0 +1,70 @@
> +
> + Subsystem Trace Points: power
> +
> +The power tracing system captures events related to power transitions
> +within the kernel. Broadly speaking there are three major subheadings:
> +
> + o Power state switch which reports events related to suspend (S-states),
> + cpuidle (C-states) and cpufreq (P-states)
> + o System clock related changes
> + o Power domains related changes and transitions
> +
> +This document describes what each of the tracepoints is and why they
> +might be useful.
> +
> +Cf. include/trace/events/power.h for the events definitions.
> +
> +1. Power state switch events
> +============================
> +
> +power_switch_state type=%lu state=%lu sub_state=%lu cpu_id=%lu
> +
> +The 'type' parameter takes one of those macros:
> + . POWER_NONE = 0,
> + . POWER_CSTATE = 1, /* C-State */
> + . POWER_PSTATE = 2, /* Fequency change or DVFS */
> + . POWER_SSTATE = 3, /* Suspend */
This POWER_SSTATE thing seems to be totally artificial and omap-specific.
Why do you want it to be done this way?
Or is the ACPI handling added in the ACPI patch? In which case, why don't you
put that power_switch_state(POWER_SSTATE, 1, 0, cpu) into
kernel/power/suspend.c:suspend_enter() (and analogously for
power_switch_state(POWER_SSTATE, 0, 0, cpu)).
Moreover, why is the cpu argument necessary for POWER_SSTATE at all?
Thanks,
Rafael
next prev parent reply other threads:[~2010-09-22 18:50 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-07 7:21 [PATCH] tracing, perf: add more power related events Jean Pihet
2010-09-07 8:01 ` Jean Pihet
2010-09-08 6:53 ` Ingo Molnar
2010-09-09 7:15 ` Jean Pihet
2010-09-09 7:54 ` Ingo Molnar
2010-09-15 15:45 ` Jean Pihet
2010-09-17 13:08 ` Thomas Renninger
2010-09-17 14:05 ` Jean Pihet
2010-09-17 14:24 ` Ingo Molnar
2010-09-17 15:36 ` Thomas Renninger
2010-09-17 16:24 ` Ingo Molnar
2010-09-17 22:26 ` Thomas Renninger
2010-09-22 15:31 ` Jean Pihet
2010-09-22 15:33 ` Arjan van de Ven
2010-09-22 15:36 ` Jean Pihet
2010-09-22 16:32 ` Arjan van de Ven
2010-09-22 16:43 ` Peter Zijlstra
2010-09-22 17:06 ` Arjan van de Ven
2010-09-22 17:30 ` Peter Zijlstra
2010-09-22 18:15 ` Steven Rostedt
2010-09-22 18:23 ` Ingo Molnar
2010-09-22 18:30 ` Peter Zijlstra
2010-09-22 18:26 ` Peter Zijlstra
2010-09-22 18:36 ` Steven Rostedt
2010-09-22 18:43 ` Peter Zijlstra
2010-09-22 19:14 ` Frank Ch. Eigler
2010-09-22 17:36 ` Thomas Renninger
2010-09-22 16:47 ` Peter Zijlstra
2010-09-22 17:57 ` Thomas Renninger
2010-09-22 18:13 ` Arjan van de Ven
2010-09-22 18:34 ` Thomas Renninger
2010-09-22 18:09 ` Rafael J. Wysocki
2010-09-22 18:49 ` Rafael J. Wysocki [this message]
2010-09-28 8:35 ` Jean Pihet
2010-09-28 21:22 ` Rafael J. Wysocki
2010-09-28 21:43 ` Jean Pihet
2010-09-28 22:05 ` Rafael J. Wysocki
2010-09-28 21:45 ` Arjan van de Ven
2010-09-28 22:05 ` Rafael J. Wysocki
2010-09-29 7:49 ` Thomas Renninger
2010-09-29 9:25 ` Jean Pihet
2010-10-04 17:55 ` [linux-pm] " Pavel Machek
2010-09-17 15:29 ` Thomas Renninger
2010-09-17 21:58 ` Thomas Renninger
2010-09-17 22:04 ` Thomas Renninger
2010-09-17 22:10 ` Thomas Renninger
2010-09-17 22:17 ` Thomas Renninger
2010-09-17 8:28 ` [tip:perf/core] tracing, perf: Add " tip-bot for Jean Pihet
-- strict thread matches above, loose matches on Subject: below --
2010-08-16 11:09 [PATCH] tracing, perf: add " Jean Pihet
2010-08-16 11:15 ` Peter Zijlstra
2010-08-16 11:25 ` Jean Pihet
2010-08-23 10:25 ` Jean Pihet
2010-09-03 17:00 ` Jean Pihet
2010-09-03 18:05 ` Thomas Renninger
2010-09-03 19:55 ` Ingo Molnar
2010-09-03 20:10 ` Thomas Renninger
2010-09-03 20:28 ` Ingo Molnar
2010-09-03 22:56 ` Arjan van de Ven
2010-09-04 8:18 ` Ingo Molnar
2010-09-06 8:56 ` Jean Pihet
2010-09-06 10:42 ` Thomas Renninger
2010-09-06 11:27 ` Jean Pihet
2010-09-06 12:00 ` Thomas Renninger
2010-09-07 7:28 ` Jean Pihet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201009222049.18154.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=arjan@infradead.org \
--cc=arjan@linux.intel.com \
--cc=jean.pihet@newoldbits.com \
--cc=khilman@deeprootsystems.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-pm@lists.linux-foundation.org \
--cc=linux-trace-users@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=trenn@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox