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

[Jiri Olsa]

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