Re: [BUG] perf report: ordered events and flushing bug

[Arnaldo Carvalho de Melo <acme@redhat.com>]

Em Thu, Mar 12, 2015 at 04:06:46PM -0400, Stephane Eranian escreveu:
> On Thu, Mar 12, 2015 at 3:53 PM, David Ahern <dsahern@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.




 
> t0: 0x100000-0x200000 //anon
> 
> t10: sample @ 0x100600
> t20: sample @ 0x100250
> 
> t1: 0x100600-0x100700 jit2
> t2: 0x100200-0x100300 jit3
> 
> with t1 < t2 < t2 < t10
> 
> I inject t1, t2 mmaps at the end of the perf.data file.
> 
> The full ordering should yield:
> 
> t0: 0x100000-0x200000 //anon
> t1: 0x100600-0x100700 jit2
> t2: 0x100200-0x100300 jit3
> t10: sample @ 0x100600 -> jit2
> t20: sample @ 0x100250 -> jit3
> 
> Partial ordering would likely yield both samples pointing to //anon.