Hi Arnaldo, On Thu, Mar 12, 2015 at 05:50:53PM -0300, Arnaldo Carvalho de Melo wrote: > Em Thu, Mar 12, 2015 at 04:06:46PM -0400, Stephane Eranian escreveu: > > On Thu, Mar 12, 2015 at 3:53 PM, David Ahern <dsah...@gmail.com> wrote: > > > On 3/12/15 1:39 PM, Stephane Eranian wrote: > > >> > > >> What the point of having all the ordered event logic if you are saying > > >> events > > >> must be saved in order. I don't think there is a way to make that > > >> guarantee > > >> when monitoring multiple CPUs at the same time. > > > > > > > > > The record command does not analyze the events, it just copies from mmap > > > to > > > file in lumps per mmap. e.g., on a given round the perf data file has > > > events > > > like this: > > > > > > 111112223344444444555566666F111111111 > > > |<------- round --------->|^ > > > | > > > finished round event -| > > > > > > where 11111 are events read from mmap1, 2222 are events from mmap2, etc. F > > > is the finished round event which a pass over all mmaps has been done. > > > > > > So for mmap1 all of the 11111 events are in time order, then jumping to > > > mmap2 events the 2222 times are time sorted relative to mmap2 but not > > > relative to mmap1 events. > > > > > > The ordered events code sorts the clumps into a time based stream: > > > 123141641445124564234645656... > > > > > In my case I care about time ordering the mmap records between themselves > > because they overlap on the address range. > > Right, Namhyung, do you keep all the MMAP records as well? Looking at > the threaded patchkit I see: > > ----------------- > [PATCH 23/38] perf tools: Add a test case for timed map groups handling > > A test case for verifying thread->mg and ->mg_list handling during > time change and new thread__find_addr_map_time() and friends. > ----------------- > > You said: > > Subject: [PATCH 19/37] perf tools: Introduce > thread__find_addr_location_time() and friends > > The *_time() variants are for find appropriate map (and symbol) at the > given time. This is based on the fact that map_groups list is sorted > by time in the previous patch. > ---------------- > > Running out of time here, but I couldn't find code where you keep > 'struct map' that overlaps and that could then be looked up using > timestamp in addition to the addr being looked up, that is needed for > parallely process samples having first processed all PERF_RECORD_MMAP > events.
It currently keeps only 'map_groups' per fork/exec so overlapped 'struct map' are not treated well assuming it's a rare event. But with the JIT map injection, it certainly also needs to keep 'struct map' by timestamp - I'll work on it for the next spin. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
