On Sunday 10 October 2010 14:19:28 Ingo Molnar wrote:
* Arjan van de Ven ar...@linux.intel.com wrote:
...
also I have to say that some events are more likely to change than others
function foo in the kernel called is more likely to change than the
processor went to THIS frequency.
* Thomas Renninger tr...@suse.de wrote:
Most definitely. It's no accident that it took such a long time for this
issue
to be raised in the first place. It's a rare occurance -
Do you agree that this occurance happened now and these events should get
cleaned
up before ARM and other
* Peter Zijlstra pet...@infradead.org wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renninger tr...@suse.de wrote:
Most definitely. It's no accident that it took such a long time for
this issue
to be raised in the first place. It's a rare occurance
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renninger tr...@suse.de wrote:
Most definitely. It's no accident that it took such a long time for this
issue
to be raised in the first place. It's a rare occurance -
Do you agree that this occurance happened now
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstrapet...@infradead.org wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renningertr...@suse.de wrote:
Most definitely. It's no accident that it took such a long time for this issue
to be raised in the first
* Arjan van de Ven ar...@linux.intel.com wrote:
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstrapet...@infradead.org wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renningertr...@suse.de wrote:
Most definitely. It's no accident that it took such a
On 10/19/2010 6:50 AM, Ingo Molnar wrote:
* Arjan van de Venar...@linux.intel.com wrote:
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstrapet...@infradead.org wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renningertr...@suse.de wrote:
Most
On Sat, Oct 9, 2010 at 8:36 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Sat, Oct 9, 2010 at 1:14 AM, Pierre Tardy tar...@gmail.com wrote:
On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar mi...@elte.hu wrote:
The thing is, Arjan is 100% right that a library for this is not a
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
* Arjan van de Ven ar...@linux.intel.com wrote:
On 10/8/2010 11:28 PM, Ingo Molnar wrote:
* Mathieu Desnoyersmathieu.desnoy...@efficios.com wrote:
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about
On Sun, 2010-10-10 at 08:41 +0200, Peter Zijlstra wrote:
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
* Mathieu Desnoyers mathieu.desnoy...@efficios.com wrote:
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing/instrumentation is that there
are no deep ABI needs: it's all about analyzing development kernels
On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar mi...@elte.hu wrote:
The thing is, Arjan is 100% right that a library for this is not a
'solution', it's an unnecessary complication.
Yes. sounds like overengineering.
If we need to change events, we can add a new event. The old events will
lose
On 10/8/2010 11:28 PM, Ingo Molnar wrote:
* Mathieu Desnoyersmathieu.desnoy...@efficios.com wrote:
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing/instrumentation is that there
are no deep ABI needs: it's all
On Sat, Oct 9, 2010 at 1:14 AM, Pierre Tardy tar...@gmail.com wrote:
On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar mi...@elte.hu wrote:
The thing is, Arjan is 100% right that a library for this is not a
'solution', it's an unnecessary complication.
Yes. sounds like overengineering.
I also
On Sat, 2010-10-09 at 11:36 -0700, Linus Torvalds wrote:
On Sat, Oct 9, 2010 at 1:14 AM, Pierre Tardy tar...@gmail.com wrote:
On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar mi...@elte.hu wrote:
The thing is, Arjan is 100% right that a library for this is not a
'solution', it's an
On Sat, 2010-10-09 at 09:19 -0700, Arjan van de Ven wrote:
I.e. it's not an ABI in the classic sense - we do not (because we
cannot) guarantee the infinite availability of these events. But we can
guarantee that the fields do not change in some stupid, avoidable way.
also I have to say
On Sat, Oct 9, 2010 at 2:15 PM, Steven Rostedt rost...@goodmis.org wrote:
The difference here compared to all other user interfaces, is that this
interface has the sole purpose of showing what is happening inside the
kernel.
Bogus and dishonest argument.
Listen to yourself, and read this
On Sat, 2010-10-09 at 16:20 -0700, Linus Torvalds wrote:
On Sat, Oct 9, 2010 at 2:15 PM, Steven Rostedt rost...@goodmis.org wrote:
The difference here compared to all other user interfaces, is that this
interface has the sole purpose of showing what is happening inside the
kernel.
Hello,
On 10/07/2010 05:58 PM, Frederic Weisbecker wrote:
I really feel uncomfortable with this tracepoint/ABI problem
Mathieu suggested we start a user library that could handle these
changes when they are really necessary.
Thoughts?
(Adding Tejun in Cc).
Given that tracepoints are
* Tejun Heo t...@kernel.org wrote:
Hello,
On 10/07/2010 05:58 PM, Frederic Weisbecker wrote:
I really feel uncomfortable with this tracepoint/ABI problem
Mathieu suggested we start a user library that could handle these
changes when they are really necessary.
Thoughts?
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing/instrumentation is that there are no
deep ABI needs: it's all about analyzing development kernels (and a few
select versions that get the enterprise treatment) but otherwise the
half-life of this kind of information
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing/instrumentation is that there are no
deep ABI needs: it's all about analyzing development kernels (and a few
select versions that get the enterprise treatment) but
On 10/8/2010 6:41 AM, Mathieu Desnoyers wrote:
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing/instrumentation is that there are no
deep ABI needs: it's all about analyzing development kernels (and a few
select
On Fri, 2010-10-08 at 09:22 -0700, Arjan van de Ven wrote:
On 10/8/2010 6:41 AM, Mathieu Desnoyers wrote:
because that is not workable... at least nobody has shown to be able to
make this work.
libraries (after compilation) live in /lib or /usr/lib (or lib64 I
suppose).
what mechanism
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 6:41 AM, Mathieu Desnoyers wrote:
* Arjan van de Ven (ar...@linux.intel.com) wrote:
On 10/8/2010 1:38 AM, Ingo Molnar wrote:
The fundamental thing about tracing/instrumentation is that there are no
deep ABI needs: it's all
Hi -
On Fri, Oct 08, 2010 at 01:21:35PM -0400, Steven Rostedt wrote:
[...]
Perhaps we should have make install of a kernel also install this
library?
[...]
The app only needs to worry about loading the generic library. The
generic library can test for compatible libraries for the kernel.
On Fri, 2010-10-08 at 13:49 -0400, Frank Ch. Eigler wrote:
Hi -
On Fri, Oct 08, 2010 at 01:21:35PM -0400, Steven Rostedt wrote:
[...]
Perhaps we should have make install of a kernel also install this
library?
[...]
The app only needs to worry about loading the generic library. The
[ Adding a few more CCs, since this discussion is about a tracepoint
userspace ABI policy, which is a topic of general interest. ]
* Thomas Renninger (tr...@suse.de) wrote:
Hi,
On Monday 04 October 2010 17:20:57 Jean Pihet wrote:
Here is a re-spin of the patches after discussion.
what
On Thu, Oct 7, 2010 at 5:08 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
[ Adding a few more CCs, since this discussion is about a tracepoint
userspace ABI policy, which is a topic of general interest. ]
To add a little more comment, this is not the first time that
tracepoints
On Thu, 2010-10-07 at 17:23 +0200, Pierre Tardy wrote:
actually, over all the events pytimechart supports, only power traces
are stable...
Let me rephrase that for you...
actually, over all the events pytimechart supports, only power traces
are inflexible...
-- Steve
--
To unsubscribe
Hi,
On Thu, Oct 7, 2010 at 5:08 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
[ Adding a few more CCs, since this discussion is about a tracepoint
userspace ABI policy, which is a topic of general interest. ]
* Thomas Renninger (tr...@suse.de) wrote:
Hi,
On Monday 04 October
On Thursday 07 October 2010 17:08:25 Mathieu Desnoyers wrote:
[ Adding a few more CCs, since this discussion is about a tracepoint
userspace ABI policy, which is a topic of general interest. ]
...
Yes, sadly this debate running in circles hurts contributors.
Thanks for the summary!
Thomas,
On Thu, Oct 7, 2010 at 5:49 PM, Thomas Renninger tr...@suse.de wrote:
On Thursday 07 October 2010 17:08:25 Mathieu Desnoyers wrote:
[ Adding a few more CCs, since this discussion is about a tracepoint
userspace ABI policy, which is a topic of general interest. ]
...
Yes, sadly
On Thu, Oct 07, 2010 at 05:23:43PM +0200, Pierre Tardy wrote:
On Thu, Oct 7, 2010 at 5:08 PM, Mathieu Desnoyers
mathieu.desnoy...@efficios.com wrote:
[ Adding a few more CCs, since this discussion is about a tracepoint
userspace ABI policy, which is a topic of general interest. ]
To add
I did told you that it would be better you make PyTimeChart use the perf
scripting facilities, it handles all the above things + it would
avoid you to handle a lot of things.
Actually, perf scripting facility is already supported by pytimechart
but does not make it that easier to maintain.
Hi,
On Monday 04 October 2010 17:20:57 Jean Pihet wrote:
Here is a re-spin of the patches after discussion.
what is going to happen here now?
Is this supposed to go through Ingo's tree?
Ingo: do you mind commenting on this.
I see 3 possibilities:
1) Power (or all) perf events are never
Here is a re-spin of the patches after discussion.
It includes:
- clean-up of the API,
- a deprecation process for backward compatibility,
- support for x86 and OMAP processors,
- support for the following tracepoints: cpuidle, cpufreq,
system suspend, clocks power domains
ToDO:
-
38 matches
Mail list logo
