* Arjan van de Ven wrote:
> >> for some time software needs to support both, especially if popular
> >> distros
> >> stick to an older kernel like *cough* RHEL6
> >
> > Sure, you can support both. But as long as support for the _new_ events is
> > included in PowerTop there's no need to keep
On 10/19/2010 6:50 AM, Ingo Molnar wrote:
* Arjan van de Ven wrote:
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renninger wrote:
Most definitely. It's no accident that it took such a long time for
* Arjan van de Ven wrote:
> On 10/19/2010 4:52 AM, Ingo Molnar wrote:
> >* Peter Zijlstra wrote:
> >
> >>On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
> >>>* Thomas Renninger wrote:
> >>>
> >Most definitely. It's no accident that it took such a long time for this
> >issue
> >
On 10/19/2010 4:52 AM, Ingo Molnar wrote:
* Peter Zijlstra wrote:
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
* Thomas Renninger 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
On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
>
> * Thomas Renninger 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
* Peter Zijlstra wrote:
> On Tue, 2010-10-19 at 13:45 +0200, Ingo Molnar wrote:
> >
> > * Thomas Renninger 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 -
> > >
> > > D
* Thomas Renninger 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 arch
On Sunday 10 October 2010 14:19:28 Ingo Molnar wrote:
>
> * Arjan van de Ven 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". The conc
On Sat, Oct 9, 2010 at 8:36 PM, Linus Torvalds
wrote:
> On Sat, Oct 9, 2010 at 1:14 AM, Pierre Tardy wrote:
>> On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar wrote:
>>>
>>
>>> The thing is, Arjan is 100% right that a library for this is not a
>>> 'solution', it's an unnecessary complication.
>> Yes
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
* Arjan van de Ven wrote:
> On 10/8/2010 11:28 PM, Ingo Molnar wrote:
> >* 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 dee
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
On Sat, 2010-10-09 at 16:20 -0700, Linus Torvalds wrote:
> On Sat, Oct 9, 2010 at 2:15 PM, Steven Rostedt 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 dis
On Sat, Oct 9, 2010 at 2:15 PM, Steven Rostedt 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 thread again.
The
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 t
On Sat, 2010-10-09 at 11:36 -0700, Linus Torvalds wrote:
> On Sat, Oct 9, 2010 at 1:14 AM, Pierre Tardy wrote:
> > On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar wrote:
> >>
> >
> >> The thing is, Arjan is 100% right that a library for this is not a
> >> 'solution', it's an unnecessary complication.
On Sat, Oct 9, 2010 at 1:14 AM, Pierre Tardy wrote:
> On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar 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 want to remind people th
On 10/8/2010 11:28 PM, Ingo Molnar wrote:
* 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 ker
On Sat, Oct 9, 2010 at 8:28 AM, Ingo Molnar 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 their rele
* 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 sele
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 l
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 ker
* 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:
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 mech
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 ve
* 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 treatmen
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 is
* Tejun Heo 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?
> >
> > (
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 tracepoin
> 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.
On Thu, Oct 07, 2010 at 05:23:43PM +0200, Pierre Tardy wrote:
> On Thu, Oct 7, 2010 at 5:08 PM, 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. ]
>
> To add a little more comment,
Thomas,
On Thu, Oct 7, 2010 at 5:49 PM, Thomas Renninger 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 this de
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!
Hi,
On Thu, Oct 7, 2010 at 5:08 PM, 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. ]
>
> * Thomas Renninger (tr...@suse.de) wrote:
>> Hi,
>>
>> On Monday 04 October 2010 17:20:57 Jean P
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 unsubscri
On Thu, Oct 7, 2010 at 5:08 PM, 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. ]
To add a little more comment, this is not the first time that
tracepoints ABI changes. You can look at p
[ 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.
>
>
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 goi
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:
- documentati
39 matches
Mail list logo
