[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1291603026-11785-1-git-send-email-imunsie@au1.ibm.com>
Date: Mon, 6 Dec 2010 13:37:03 +1100
From: "Ian Munsie" <imunsie@....ibm.com>
To: linux-kernel <linux-kernel@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>
Cc: Frederic Weisbecker <fweisbec@...il.com>,
Mike Galbraith <efault@....de>,
Paul Mackerras <paulus@...ba.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Stephane Eranian <eranian@...gle.com>
Subject: Process events in order if recording from multiple CPUs
Hi all,
Here are my set of patches to process events in order and solve the bug where
samples would not be attributed correctly if the COMM and MMAP events for them
had not yet been processed.
I ran out of time cleaning these on Friday and hadn't touched them over the
weekend. I see Thomas has now already posted a patch that does most of what the
third patch in this series does, and this series would supersede his patch, my
apologies for not getting these out last week.
In addition to what Thomas' patch does, patch 3 in this series:
- Enables the PERF_SAMPLE_TIME flag automatically when recording if recording
from multiple CPUs (ie, if no_inherit is not set). This flag will be
disabled if the kernel does not support timestamps on every event and was
not manually requested.
- Enables ordered_samples in perf report by default.
- If an event is encountered without a timestamp, fall back to processing in
file order (otherwise we might process a PERF_RECORD_EXIT event too early).
Thomas' patch does change some names that I did not ('self' -> 'session'), but
those should be pretty straight forward to put in their own patch on top of
these.
The first patch in this series changes how unresolved symbols are printed out
and the second patch moves some debugging output into the trace_event function
to keep the debugging output sensible when processing events by timestamp.
Cheers,
-Ian
--
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