linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Pierre Tardy <tardyp@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Tom Zanussi <tzanussi@gmail.com>,
	Paul Mackerras <paulus@samba.org>,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org,
	mathieu.desnoyers@efficios.com, arjan@infradead.org,
	ziga.mahkovec@gmail.com
Subject: Re: [RFC] PyTimechart
Date: Wed, 12 May 2010 16:48:19 +0200	[thread overview]
Message-ID: <20100512144811.GA5405@nowhere> (raw)
In-Reply-To: <AANLkTikumkBKwYTYIK63mT2i_hI4SAo-Eua0cx9OCHnD@mail.gmail.com>

On Wed, May 12, 2010 at 03:37:27PM +0200, Pierre Tardy wrote:
> > Plugging to the scripting API is really easy, run:
> >
> >        $ perf timechart record
> >        $ sudo ./perf trace -g python
> >        generated Python script: perf-trace.py
> 
> This is something that I want to try since I saw the perf scripting
> patch, thanks for the recipe, I'll look at it in the next few days.
> 
> The next problem is that perf timechart record is frozen on the number
> of event it records.



What do you mean? That it can't do incremental records or so?
It's supported by perf record, may be not by perf timechart but
that would be a matter of a little patch.


> Pytimechart is able to display irq:* and workqueues:* events, as well
> as trace_printks ( I dont know if perf is able to dump those )
> 
> I use trace_printk to mark the big traces with events I'm trying to debug.
> Being able to look at ISR and workqueues is very useful, and there is
> a special feature that warns when an ISR lasts more than 1ms.


No problem with the irq and workqueues, if that's really useful, we
can change perf timechart to handle this.

But we don't yet support trace_printk in perf. May be we could wrap
them in trace events.

Why not starting with a release that does the same things
than timechart and trying to integrate the rest incrementally?


> For inclusion in mainline, this might take more time. The quality of
> some portion of the code is far from being linux kernel's standards
> :-}


The code I'm looking at here doesn't look dirty to me at a glance:
http://gitorious.org/pytimechart/pytimechart/trees/master


  reply	other threads:[~2010-05-12 14:48 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-11 21:10 [RFC] PyTimechart Pierre Tardy
2010-05-11 21:36 ` Frederic Weisbecker
2010-05-12 13:37   ` Pierre Tardy
2010-05-12 14:48     ` Frederic Weisbecker [this message]
2010-05-12 15:36       ` Steven Rostedt
2010-05-12 16:46         ` Perf and ftrace [was Re: PyTimechart] Frederic Weisbecker
2010-05-12 17:00           ` Peter Zijlstra
2010-05-12 17:07             ` Mathieu Desnoyers
2010-05-12 17:47               ` Peter Zijlstra
2010-05-12 17:53                 ` Mathieu Desnoyers
2010-05-12 18:00                   ` Peter Zijlstra
2010-05-12 18:04                     ` Mathieu Desnoyers
2010-05-12 18:08                       ` Peter Zijlstra
2010-05-12 18:37                         ` Mathieu Desnoyers
2010-05-12 18:46                           ` Steven Rostedt
2010-05-12 20:27                             ` Mathieu Desnoyers
2010-05-12 22:21                               ` Steven Rostedt
2010-05-13 13:20                                 ` Mathieu Desnoyers
2010-05-13 15:42                                   ` Steven Rostedt
2010-05-13 16:31                                     ` Mathieu Desnoyers
2010-05-13 16:46                                       ` Steven Rostedt
2010-05-13 17:10                                         ` Mathieu Desnoyers
2010-05-13 18:33                                           ` Steven Rostedt
2010-05-14  7:53                                       ` Peter Zijlstra
2010-05-12 18:49                           ` Peter Zijlstra
2010-05-12 18:51                             ` Mathieu Desnoyers
2010-05-12 19:01                               ` Peter Zijlstra
2010-05-12 20:52                                 ` Mathieu Desnoyers
2010-05-12 17:11             ` Ingo Molnar
2010-05-12 16:59         ` [RFC] PyTimechart Ingo Molnar
2010-05-12 17:15           ` Steven Rostedt
2010-05-12 18:23             ` Ingo Molnar
2010-05-12 17:13       ` Pierre Tardy
2010-05-13 15:02         ` Arnaldo Carvalho de Melo

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=20100512144811.GA5405@nowhere \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=arjan@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=rostedt@goodmis.org \
    --cc=tardyp@gmail.com \
    --cc=tzanussi@gmail.com \
    --cc=ziga.mahkovec@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).