lkml.org 
[lkml]   [2019]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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

\
 
 \ /
  Last update: 2019-03-14 10:02    [W:0.060 / U:4.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site