From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Pierre Tardy <tardyp@gmail.com>, Ingo Molnar <mingo@elte.hu>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Arjan van de Ven <arjan@linux.intel.com>,
Tejun Heo <tj@kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Thomas Renninger <trenn@suse.de>,
Jean Pihet <jean.pihet@newoldbits.com>,
linux-trace-users@vger.kernel.org,
linux-pm@lists.linux-foundation.org,
linux-perf-users@vger.kernel.org, rjw@sisk.pl,
linux-omap@vger.kernel.org,
Kevin Hilman <khilman@deeprootsystems.com>,
Frank Eigler <fche@redhat.com>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: PATCH [0/4] perf: clean-up of power events API
Date: Sun, 10 Oct 2010 08:41:21 +0200 [thread overview]
Message-ID: <1286692881.1998.10.camel@laptop> (raw)
In-Reply-To: <1286674768.23994.3915.camel@gandalf.stny.rr.com>
On Sat, 2010-10-09 at 21:39 -0400, Steven Rostedt wrote:
> I've been hesitant in the pass from doing the TRACE_EVENT_ABI()
> before, because Peter Zijlstra (who is currently MIA) has been strongly
> against it.
I see no point in the TRACE_EVENT_ABI() because if I need to change such
a tracepoint to reflect changes in the kernel then I will freely do so.
Even seemingly stable points like sched_switch(), which we all agree
will stay around forever (gotta have context switches on a multi-tasking
OS) will not stay stable when we add/change scheduling policies.
Sure, the prev and next task thing will stay the same, but the meaning
and interpretation of things like the prio field will not, esp when we
go add something like a deadline scheduler that isn't priority based.
So one possibility is to simply remove all that information from the
tracepoints, remove the prio and state fields, but how useful is that?
I guess what I'm saying is that even if we were to provide _ABI I see us
getting into this very same argument over and over again, making me want
to remove all this trace event muck right now before it gets worse.
next prev parent reply other threads:[~2010-10-10 6:41 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 15:20 PATCH [0/4] perf: clean-up of power events API Jean Pihet
2010-10-04 15:20 ` [PATCH 1/4] perf: cleanup " Jean Pihet
2010-10-04 15:20 ` [PATCH 2/4] perf: add OMAP support for the new power events Jean Pihet
2010-10-04 19:45 ` Thomas Renninger
2010-10-04 15:21 ` [PATCH 3/4] perf: add calls to suspend trace point Jean Pihet
2010-10-04 22:52 ` Rafael J. Wysocki
2010-10-04 15:21 ` [PATCH 4/4] perf: provide a DEPRECTAED power trace API to user space Jean Pihet
2010-10-04 16:10 ` Frank Ch. Eigler
2010-10-04 16:47 ` Jean Pihet
2010-10-06 21:34 ` PATCH [0/4] perf: clean-up of power events API Thomas Renninger
2010-10-07 15:08 ` Mathieu Desnoyers
2010-10-07 15:23 ` Pierre Tardy
2010-10-07 15:45 ` Steven Rostedt
2010-10-07 15:58 ` Frederic Weisbecker
2010-10-07 16:10 ` Pierre Tardy
2010-10-08 8:14 ` Tejun Heo
2010-10-08 8:38 ` Ingo Molnar
2010-10-08 13:17 ` Arjan van de Ven
2010-10-08 13:41 ` Mathieu Desnoyers
2010-10-08 16:22 ` Arjan van de Ven
2010-10-08 17:21 ` Steven Rostedt
2010-10-08 17:49 ` Frank Ch. Eigler
2010-10-08 18:11 ` Steven Rostedt
2010-10-08 17:32 ` Mathieu Desnoyers
2010-10-09 6:28 ` Ingo Molnar
2010-10-09 8:14 ` Pierre Tardy
2010-10-09 18:36 ` Linus Torvalds
2010-10-09 21:15 ` Steven Rostedt
2010-10-09 23:20 ` Linus Torvalds
2010-10-10 1:39 ` Steven Rostedt
2010-10-10 6:41 ` Peter Zijlstra [this message]
2010-10-10 15:11 ` Steven Rostedt
2010-10-18 12:15 ` Jean Pihet
2010-10-09 16:19 ` Arjan van de Ven
2010-10-09 21:34 ` Steven Rostedt
2010-10-10 12:19 ` Ingo Molnar
2010-10-19 11:31 ` Thomas Renninger
2010-10-19 11:45 ` Ingo Molnar
2010-10-19 11:47 ` Peter Zijlstra
2010-10-19 11:52 ` Ingo Molnar
2010-10-19 13:27 ` Arjan van de Ven
2010-10-19 13:50 ` Ingo Molnar
2010-10-19 13:52 ` Arjan van de Ven
2010-10-19 14:51 ` Ingo Molnar
2010-10-07 15:45 ` Jean Pihet
2010-10-07 15:49 ` Thomas Renninger
2010-10-07 15:56 ` 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=1286692881.1998.10.camel@laptop \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jean.pihet@newoldbits.com \
--cc=khilman@deeprootsystems.com \
--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=masami.hiramatsu.pt@hitachi.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
--cc=rostedt@goodmis.org \
--cc=tardyp@gmail.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=torvalds@linux-foundation.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