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:   Thu, 27 Sep 2018 18:01:58 +0200
From:   Jiri Olsa <jolsa@...hat.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Namhyung Kim <namhyung@...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

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 :-\

I'll try to prepare something

jirka