linux-kernel - Re: [PATCH v7 10/12] perf report: implement record trace decompression

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]

Date:   Thu, 14 Mar 2019 10:01:28 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Alexey Budankov <alexey.budankov@...ux.intel.com>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andi Kleen <ak@...ux.intel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v7 10/12] perf report: implement record trace
 decompression

On Wed, Mar 13, 2019 at 06:55:29PM +0300, Alexey Budankov wrote:
> 
> On 13.03.2019 17:37, Jiri Olsa wrote:
> > On Tue, Mar 12, 2019 at 08:36:18AM +0300, Alexey Budankov wrote:
> > 
> > SBIP
> > 
> >> +#ifdef HAVE_ZSTD_SUPPORT
> >> +static int perf_session__process_compressed_event(struct perf_session *session,
> >> +					union perf_event *event, u64 file_offset)
> >> +{
> >> +	void *src;
> >> +	size_t decomp_size, src_size;
> >> +	u64 decomp_last_rem = 0;
> >> +	size_t decomp_len = session->header.env.comp_mmap_len;
> >> +	struct decomp *decomp, *decomp_last = session->decomp_last;
> >> +
> >> +	decomp = mmap(NULL, sizeof(struct decomp) + decomp_len, PROT_READ|PROT_WRITE,
> >> +		      MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
> >> +	if (decomp == MAP_FAILED) {
> >> +		pr_err("Couldn't allocate memory for decompression\n");
> >> +		return -1;
> >> +	}
> > 
> > ok, I see the need to keep this decomp around, we need the event
> > to be there the whole time, like the mmap for the standard events
> > 
> > we know the total uncompressed size when record is done, right?
> > could we save it in the COMPRESSED feature and alloc all the
> > needed uncompressed data in single mmap?
> 
> It can be not that good idea. The required contiguous memory 
> region can be really huge to be allocated. Plain malloc()'s are 
> also not good. I was observing OOM in perf report process when 
> loading traces of several GiBs. So smaller, page size granularity,
> linked memory regions performed the best in my experiments.

ok

jirka