Re: [PATCH 47/48] perf record: Spread maps for --threads option

[Namhyung Kim]

Hi Arnaldo and Jiri,

On Thu, Sep 27, 2018 at 06:01:58PM +0200, Jiri Olsa wrote:
> On Wed, Sep 26, 2018 at 08:23:17AM +0200, Jiri Olsa wrote:
> 
> SNIP
> 
> > > I agree with Namhyung, with a slight difference: perhaps we should set
> > > perf_event_attr.mmap on one of the events of the per-cpu mmap, that way
> > > we don't need that dummy event, right?
> > 
> > currently it's all based on having tracking data separated
> > in single file which is read/processed first, so when we
> > read the sample data files, we can read them separately,
> > because we have the tracking data ready
> > 
> > >  
> > > > with the *_time API, we should be able to properly read the
> > > > tracking data separately for each cpu
> > > 
> > > That may end up making the *_time API not needed (assuming the kernel
> > > keeps the per-cpu mmap events in order, barring that, using the
> > > ordered_events in batches, prior to consuming the events) and would help
> > > with things like 'perf top' and 'perf trace', that want to consume
> > > events right away.
> > 
> > if we dont want to use *_by_time API, we need to find a way
> > to sort evevrything out before we start processing.. and that
> > seems too costly to me
> 
> actualy we might try to read all the streams at simultaneously
> and sort the samples on the fly with some reasonable sorting
> window time frame.. this way we could have just single file
> for thread and would skip the *by_time api, hopefuly :-\

Note that without the *by_time API, it only can see the last state.
For example if a task calls exec() in the middle of the window, all
the samples will be processed to the new one.  It might or might not
matter depending on the length of the window.

Thanks,
Namhyung