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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 28 Sep 2018 15:25:35 +0900
From:   Namhyung Kim <namhyung@...nel.org>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jiri Olsa <jolsa@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Andi Kleen <andi@...stfloor.org>,
        Alexey Budankov <alexey.budankov@...ux.intel.com>,
        kernel-team@....com
Subject: Re: [PATCH 47/48] perf record: Spread maps for --threads option

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