public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@infradead.org>
To: Hitoshi Mitake <mitake@dcl.info.waseda.ac.jp>
Cc: "Ingo Molnar" <mingo@elte.hu>,
	linux-kernel@vger.kernel.org,
	"Frédéric Weisbecker" <fweisbec@gmail.com>,
	"Mike Galbraith" <efault@gmx.de>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Paul Mackerras" <paulus@samba.org>
Subject: Re: [PATCH 12/12] Revert "perf record: Intercept all events"
Date: Mon, 25 Jan 2010 12:57:45 -0200	[thread overview]
Message-ID: <20100125145745.GE24418@ghostprotocols.net> (raw)
In-Reply-To: <a6b9f31a1001250647k7273ab80j771d673595d3ad80@mail.gmail.com>

Em Mon, Jan 25, 2010 at 11:47:40PM +0900, Hitoshi Mitake escreveu:
> On Mon, Jan 25, 2010 at 11:23, Arnaldo Carvalho de Melo
> <acme@infradead.org> wrote:
> > Em Fri, Jan 22, 2010 at 10:39:13PM +0900, Hitoshi Mitake escreveu:
> >> This reverts commit f5a2c3dce03621b55f84496f58adc2d1a87ca16f.
> >>
> >> This patch is required for making "perf lock rec" work.
> >> The commit f5a2c3dce0 changes write_event() of builtin-record.c .
> >> And changed write_event() sometimes doesn't stop with perf lock rec.
> >>
> >> I'm researching what makes write_event() loop infinity,
> >> and noticed that there are some events with event_t->header.size == 0.
> >> But the detail of the problem,
> >> like kind of these events, isn't clear...
> >>
> >> If you know something related to this problem,
> >> could you tell me, Arnaldo?
> >
> > Well, this will have to wait for somebody to remove the need for
> > intercepting those events, reverting this patch fixes your tool while
> > breaking others that then won't catch all the events.
> 
> Yes, this patch is too egoistic thing and temporary solution.
> I have to consider and modify 'perf lock'.

Hey, don't get me wrong, the situation is fragile, either way something
will get broken and that isn't your fault, its just that we need some
sensible and non racy way to inject the buildids at 'perf record' time.

The way I did it, long ago, intercepting events in 'perf record' to
build a DSO list to then at 'perf record' exit to insert a table at the
perf.data file header looks too intrusive now, so we need some other way
that doesn't have this problem and its not racy.
 
> > I'll get 'perf regtest' out with some initial tests then try to get some
> > proposal for injecting the buildid, if found in a DSO, via
> > PERF_RECORD_MMAP, lets see how this goes...
> 
> What does "DSO" mean? Sorry, I'm not good at English...

As Peter said, anything that that is on an executable MMAP.
 
> >
> > Best Regards,
> >
> > - Arnaldo
> >
> > BTW: I took longer to send a response to this question addressed to me
> > because I wasn't on the CC list :-)
> 
> Oh, sorry... I wonder why I didn't add you to Cc or To :(
> It is completely my mistake, and thanks for your reply!

:-) Best Regards,

- Arnaldo

  parent reply	other threads:[~2010-01-25 14:58 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-22 13:39 [PATCH 00/12] perf lock: New subcommand "perf lock", for analyzing lock statistics Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 01/12] perf tools: Add __data_loc support Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 02/12] perf: Add util/include/linuxhash.h to include hash.h of kernel Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 03/12] lockdep: Add information of file and line where lock inited to struct lockdep_map Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 04/12] lockdep: Add file and line to initialize sequence of spinlock Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 05/12] lockdep: Add file and line to initialize sequence of rwlock Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 06/12] lockdep: Add file and line to initialize sequence of rwsem Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 07/12] lockdep: Add file and line to initialize sequence of rwsem (x86) Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 08/12] lockdep: Add file and line to initialize sequence of mutex Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 09/12] lockdep: Fix the way to initialize class_mutex for information of file and line Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 10/12] perf lock: Enhance information of lock trace events Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 11/12] perf lock: New subcommand "perf lock", for analyzing lock statistics Hitoshi Mitake
2010-01-28  6:51   ` Hitoshi Mitake
2010-01-28 14:28     ` [PATCH] perf: Add util/include/linux/config.h for including generated autoconf.h of kernel Hitoshi Mitake
2010-01-28 14:44       ` Peter Zijlstra
2010-01-30 11:44         ` Hitoshi Mitake
2010-01-28 22:27       ` Paul Mackerras
2010-01-30 11:51         ` Hitoshi Mitake
2010-01-22 13:39 ` [PATCH 12/12] Revert "perf record: Intercept all events" Hitoshi Mitake
2010-01-25  2:23   ` Arnaldo Carvalho de Melo
2010-01-25 14:47     ` Hitoshi Mitake
2010-01-25 14:50       ` Peter Zijlstra
2010-01-25 14:57       ` Arnaldo Carvalho de Melo [this message]
2010-01-26  7:17         ` Hitoshi Mitake
2010-01-22 16:42 ` [PATCH 00/12] perf lock: New subcommand "perf lock", for analyzing lock statistics Jason Baron
2010-01-22 16:48   ` Peter Zijlstra
2010-01-22 16:52     ` Peter Zijlstra
2010-01-23  6:57       ` Ingo Molnar
2010-01-25 14:15   ` Hitoshi Mitake
2010-01-25 14:48     ` Peter Zijlstra
2010-01-26  7:04       ` Hitoshi Mitake
2010-01-26  4:26     ` Greg KH
2010-01-29 14:34 ` Jens Axboe
2010-01-30 12:00   ` Hitoshi Mitake
2010-01-31 20:44     ` Jens Axboe
2010-01-31 21:07       ` Frederic Weisbecker
2010-01-31 21:11         ` Jens Axboe
2010-02-01  9:15         ` Peter Zijlstra
2010-02-01  9:22           ` Ingo Molnar
2010-02-01 17:58             ` Frederic Weisbecker
2010-02-01 13:23       ` Jens Axboe

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=20100125145745.GE24418@ghostprotocols.net \
    --to=acme@infradead.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=efault@gmx.de \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mitake@dcl.info.waseda.ac.jp \
    --cc=paulus@samba.org \
    /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