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: 123+ 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 7:21 ` Jean Pihet
2010-09-07 8:01 ` Jean Pihet
2010-09-07 8:01 ` Jean Pihet
2010-09-07 8:01 ` Jean Pihet
2010-09-08 6:53 ` Ingo Molnar
2010-09-08 6:53 ` Ingo Molnar
2010-09-09 7:15 ` Jean Pihet
2010-09-09 7:15 ` Jean Pihet
2010-09-09 7:54 ` Ingo Molnar
2010-09-15 15:45 ` Jean Pihet
2010-09-15 15:45 ` Jean Pihet
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:05 ` Jean Pihet
2010-09-17 14:24 ` Ingo Molnar
2010-09-17 15:36 ` Thomas Renninger
2010-09-17 15:36 ` Thomas Renninger
2010-09-17 16:24 ` Ingo Molnar
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:31 ` Jean Pihet
2010-09-22 15:33 ` Arjan van de Ven
2010-09-22 15:36 ` Jean Pihet
2010-09-22 15:36 ` Jean Pihet
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 17:30 ` Peter Zijlstra
2010-09-22 18:15 ` Steven Rostedt
2010-09-22 18:23 ` Ingo Molnar
2010-09-22 18:23 ` Ingo Molnar
2010-09-22 18:30 ` Peter Zijlstra
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 18:43 ` Peter Zijlstra
2010-09-22 18:36 ` Steven Rostedt
2010-09-22 19:14 ` Frank Ch. Eigler
2010-09-22 19:14 ` Frank Ch. Eigler
2010-09-22 18:26 ` Peter Zijlstra
2010-09-22 18:15 ` Steven Rostedt
2010-09-22 17:36 ` Thomas Renninger
2010-09-22 17:36 ` Thomas Renninger
2010-09-22 17:06 ` Arjan van de Ven
2010-09-22 16:43 ` Peter Zijlstra
2010-09-22 16:47 ` Peter Zijlstra
2010-09-22 16:47 ` Peter Zijlstra
2010-09-22 16:32 ` Arjan van de Ven
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:34 ` Thomas Renninger
2010-09-22 18:13 ` Arjan van de Ven
2010-09-22 17:57 ` Thomas Renninger
2010-09-22 18:09 ` Rafael J. Wysocki
2010-09-22 18:09 ` Rafael J. Wysocki
2010-09-22 15:33 ` Arjan van de Ven
2010-09-22 18:49 ` Rafael J. Wysocki [this message]
2010-09-28 8:35 ` Jean Pihet
2010-09-28 8:35 ` Jean Pihet
2010-09-28 21:22 ` Rafael J. Wysocki
2010-09-28 21:22 ` Rafael J. Wysocki
2010-09-28 21:43 ` Jean Pihet
2010-09-28 21:43 ` Jean Pihet
2010-09-28 21:43 ` Jean Pihet
2010-09-28 22:05 ` Rafael J. Wysocki
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-28 22:05 ` Rafael J. Wysocki
2010-09-29 7:49 ` Thomas Renninger
2010-09-29 7:49 ` Thomas Renninger
2010-09-29 9:25 ` Jean Pihet
2010-09-29 9:25 ` Jean Pihet
2010-09-29 9:25 ` Jean Pihet
2010-10-04 17:55 ` Pavel Machek
2010-10-04 17:55 ` [linux-pm] " Pavel Machek
2010-09-28 21:45 ` Arjan van de Ven
2010-09-28 8:35 ` Jean Pihet
2010-09-22 18:49 ` Rafael J. Wysocki
2010-09-22 15:31 ` Jean Pihet
2010-09-17 22:26 ` Thomas Renninger
2010-09-17 14:24 ` Ingo Molnar
2010-09-17 15:29 ` Thomas Renninger
2010-09-17 15:29 ` Thomas Renninger
2010-09-17 21:58 ` Thomas Renninger
2010-09-17 21:58 ` Thomas Renninger
2010-09-17 22:04 ` Thomas Renninger
2010-09-17 22:04 ` Thomas Renninger
2010-09-17 22:10 ` Thomas Renninger
2010-09-17 22:10 ` Thomas Renninger
2010-09-17 22:17 ` Thomas Renninger
2010-09-17 22:17 ` Thomas Renninger
2010-09-17 13:08 ` Thomas Renninger
2010-09-09 7:54 ` Ingo Molnar
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-09-07 7:21 [PATCH] tracing, perf: add " Jean Pihet
2010-08-16 11:09 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 11:27 ` Jean Pihet
2010-09-06 12:00 ` Thomas Renninger
2010-09-07 7:28 ` Jean Pihet
2010-09-07 7:28 ` Jean Pihet
2010-09-06 12:00 ` Thomas Renninger
2010-09-06 10:42 ` Thomas Renninger
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.