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
