linux-kernel - Re: [RFC/PATCH 00/14] perf record: Add support to store data in directory

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]

Message-ID: <20190214135958.GB7074@kernel.org>
Date:   Thu, 14 Feb 2019 10:59:58 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     Stephane Eranian <eranian@...gle.com>,
        Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Andi Kleen <ak@...ux.intel.com>
Subject: Re: [RFC/PATCH 00/14] perf record: Add support to store data in
 directory

Em Thu, Feb 14, 2019 at 02:26:38PM +0100, Jiri Olsa escreveu:
> On Thu, Feb 14, 2019 at 09:57:59AM -0300, Arnaldo Carvalho de Melo wrote:
> > But with the build id in the MMAPs we wouldn't need to scan anything at
> > 'perf record' time, just at 'perf archive' time, where we would scan
> > everything, and as soon as we find a hit, we add that DSO to the list of
> > things we need to put in the tarball.

> ok.. it might little change the expected behavour in that you will not
> have .debug cache populated until you run perf archive.. some profile
> data might stop report after you reinstall the binary..

Well, nothing prevents us from continuing to, in 'perf record', go thru
the perf.data just collected to populate the .debug cache, its just that
we would do it just for that, for populating the cache, we wouldn't
_have_ to do that for collecting the buildids.

> on the other hand '.debug' cache would stop growing uncontrolably..
> so I think I'd be ok with this

That is another problem, and one that has to be solved in a way similar
to ccache's --max-size option.

The .debug cache is useful for various workflows, but may get in the way
for some others, which is why we have ways to disable it.

For instance, when working on some project it is handy to have copies of
binaries saved so that older perf.data files can find a file that was
rewritten by the compiler when doing changes in it, etc.

With the .debug cache and if using -g, we can get the older copy of the
binary _and_ its sources, annotation for older versions continue to
work, etc.

- Arnaldo