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

[Namhyung Kim <namhyung@kernel.org>]

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 <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.

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