On 12.02.2019 16:09, Jiri Olsa wrote: > On Mon, Feb 11, 2019 at 11:22:38PM +0300, Alexey Budankov wrote: > > SNIP > >> @@ -1147,6 +1193,10 @@ static int __cmd_record(struct record *rec, int argc, >> const char **argv) >> fd = perf_data__fd(data); >> rec->session = session; >> >> + rec->opts.comp_level = 0; >> + session->header.env.comp_level = rec->opts.comp_level; >> + session->header.env.comp_type = PERF_COMP_NONE; >> + >> record__init_features(rec); >> >> if (rec->opts.use_clockid && rec->opts.clockid_res_ns) >> @@ -1176,6 +1226,7 @@ static int __cmd_record(struct record *rec, int argc, >> const char **argv) >> err = -1; >> goto out_child; >> } >> + session->header.env.comp_mmap_len = session->evlist->mmap_len; > > so the comp_mmap_len is the max length of the compressed packet?
comp_mmap_len is the size of buffer to encompass one compressed chunk of data after its decompression. > > any idea if this value might have some impact on the processing speed? It increases memory consumption at the loading and processing stages. > > I see you mentioned the size reduction, could you also meassure > the record overhead? Let's get back to this after the code review. Thanks, Alexey > > thanks, > jirka >
