[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100125022351.GD24418@ghostprotocols.net>
Date: Mon, 25 Jan 2010 00:23:51 -0200
From: Arnaldo Carvalho de Melo <acme@...radead.org>
To: Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Cc: Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
Frédéric Weisbecker <fweisbec@...il.com>,
Mike Galbraith <efault@....de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Paul Mackerras <paulus@...ba.org>
Subject: Re: [PATCH 12/12] Revert "perf record: Intercept all events"
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.
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...
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 :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists