linux-kernel - Re: [PATCH 3/4] perf record: event synthesization multithreading support

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] [day] [month] [year] [list]

Message-ID: <20171013200658.gokyihds32ftwgy5@gmail.com>
Date:   Fri, 13 Oct 2017 22:06:58 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     kan.liang@...el.com, peterz@...radead.org, mingo@...hat.com,
        linux-kernel@...r.kernel.org, jolsa@...nel.org,
        wangnan0@...wei.com, hekuang@...wei.com, namhyung@...nel.org,
        alexander.shishkin@...ux.intel.com, adrian.hunter@...el.com,
        ak@...ux.intel.com
Subject: Re: [PATCH 3/4] perf record: event synthesization multithreading
 support


* Arnaldo Carvalho de Melo <acme@...nel.org> wrote:

> Em Fri, Oct 13, 2017 at 07:09:26AM -0700, kan.liang@...el.com escreveu:
> > From: Kan Liang <Kan.liang@...el.com>
> > 
> > The process function process_synthesized_event writes the process
> > result to perf.data, which is not multithreading friendly.
> > 
> > Realloc buffer for each thread to temporarily keep the processing
> > result. Write them to the perf.data at the end of event synthesization.
> > The new method doesn't impact the final result, because
> >  - The order of the synthesized event is not important.
> >  - The number of synthesized event is limited. Usually, it only needs
> >    hundreds of Kilobyte to store all the synthesized event.
> >    It's unlikly failed because of lack of memory.
> 
> Why not write to a per cpu file and then at the end merge them? Leave
> the memory management to the kernel, i.e. in most cases you may even not
> end up touching the disk, when memory is plentiful, just rewind the per
> event files and go on dumping to the main perf.data file.
> 
> At some point we may just don't do this merging, and keep per cpu files
> all the way to perf report, etc. This would be a first foray into
> that...

Yeah, that sounds like a really good zero-copy recording scheme, and I bet it 
would scale like a crazed bat out of hell!

Thanks,

	Ingo